feat/catalog transitions - #3194

Check if this issue is valid — if so, understand the root cause and fix it. At server/src/internal/catalogV2/actions/updateCatalog/errors/handleUpdateCatalogErrors.ts, line 181:

<comment>detectOrphanedActivePointers only catches the case where the active version remains in the projection as archived. When a live active version is removed as a single (non-all_versions) version with no customers and no rewards, stampRemoveWillArchive hard-deletes it (willArchive=false), so projectCatalog drops the row entirely. The plan's surviving versions then have no active row, activeRow is undefined, and the orphaned active pointer passes this check — exactly the state the feature docstring says must be prevented. Consider flagging plans that have a surviving non-archived version but no active row. Note the primary archive path (active version removed with a surviving version) is detected correctly.</comment>

<file context>
@@ -177,6 +178,7 @@ export const handleUpdateCatalogErrors = async ({
 	});
 	handleUpsertProductVersionSlugErrors({ updateCatalogPlan });
 	handleUpsertProductActiveErrors({ params });
+	handleActivePointerErrors({ updateCatalogPlan });
 	handleUpsertProductErrors({
 		updateCatalogPlan,
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At server/src/internal/catalogV2/actions/updateCatalog/compute/computeMigrationDraftPlans/matchingDraftPlanParams.ts, line 87:

<comment>A request-level `migration.draft` claims every row and short-circuits per-plan flags, so no plan entry can opt a row back out of drafting. The schema comment in this PR calls the field "overridable per plan," but `params.migration?.draft === true ||` runs before `matchingDraftPlanParams`, so `migration: { draft: false }` on a plan is ignored once the request-level flag is set. A config client that wants to exclude a specific plan from a request-wide draft has no way to do so.</comment>

<file context>
@@ -72,13 +72,20 @@ export const matchingDraftPlanParams = ({
 	params: UpdateCatalogParams;
-}): boolean => matchingDraftPlanParams({ upsertProductPlan, params }) != null;
+}): boolean =>
+	params.migration?.draft === true ||
+	matchingDraftPlanParams({ upsertProductPlan, params }) != null;
 
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At server/tests/integration/catalog-v2/plans/validation/transition-impossibilities.test.ts, line 26:

<comment>The header documents F1 as "Red (current)" and says the update is "accepted," but the first test in this file asserts the opposite — it expects the orphaned-pointer archive to reject and the row to stay unarchived. The refusal logic landed in this PR ("refuse to leave a live plan on an archived version"), so the test is green now. Remove or rewrite the stale "Red (current)" paragraph so the contract comment matches the current behavior.</comment>

<file context>
@@ -0,0 +1,176 @@
+ *   F3  an internal_id rename carries the plan's whole history, pointer
+ *       included — the row addressed is the handle, not the scope
+ *
+ * Red (current): nothing inspects the projected active pointer, so F1 is
+ *   accepted and the plan is left current-versionless.
+ * Green (after): F1 is a 400 naming the row in the way.
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At server/tests/integration/catalog-v2/plans/migrations/auto-draft.test.ts, line 106:

<comment>The migration draft persists with an id of `{scope}-update-{uid}` (see buildMigrationDraftId), never the plan id, but `finally` calls `deleteMigrations({ ctx, ids: [customeredId] })` / `[planId]`. Since every sibling draft test (billing-flag, customize-buckets, draft-guards, filter-collapse) deletes via `response.migrations![0]!.id`, passing the plan id here deletes nothing, and the draft row created by the request-level flag leaks in the test DB. Capture the migration id from the response (as the other tests do) and delete that.</comment>

<file context>
@@ -0,0 +1,158 @@
+				],
+			});
+		} finally {
+			await deleteMigrations({ ctx, ids: [customeredId] });
+			await cleanupPlanCustomerRefs({
+				ctx,
</file context>